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Abstract. We present an implementation of the algoritlim for computing 
Grobner bases for operads due to the first author and A. Khoroshkin. We dis- 
cuss the actual algorithms, the choices made for the implementation platform 
and the data representation, and strengths and weaknesses of our approach. 



1. Introduction 

1.1. Summary of results. In an upcoming paper [ '>], the first author and Anton 
Khoroshkin define the concept of a Grobner basis for finitely presented operads. In 
that paper, they prove the diamond lemma, and demonstrate that for an operad, 
having a quadratic Grobner basis is equivalent to the existence of a Poincare- 
Birkhoff-Witt basis. As demonstrated by Eric Hoffbeck [ ], an operad with a PBW 
basis is Koszul. Hence, an implementation of the Grobner bases algorithm yields, in 
addition to a framework for exploration of operads by means of explicit calculation, 
a computer-aided tool for proving Koszulness. 

In this paper, we present an implementation of the Grobner basis algorithm 
in the Haskell programming language [5]. Being designed with categorical terms, 
Haskell provides a powerful framework for algorithms like that. What we end up 
with is a computer sofware package which allows to compute the Grobner basis for 
a finitely presented operad, as well as bases and dimensions for components of such 
an operad. 

One of the main goals of this paper is to help mathematicians who want to get 
familiar with this software package and use it for their needs, including changing 
some algorithms or adding more functionality.^ Consequently, this is more of an 
invitation to experiment with this software than a report on what it is possible to 
compute. Let us comment briefly on the state of the art regarding computations. 
While working on the package, we have implemented several well known operads to 
test the performance. In the case when an operad is PBW, our package captures 
that right away. This already is a very important achievement: having implemented 
many different admissible orderings, one can check very fast whether or not an 
operad is PBW for at least one of them, thus proving the Koszulness in many cases. 
Note that the PBW property depends a lot not only on the choice of an admissible 
ordering, but also on the choice of ordering of generators of our operad; for example, 
for the operad of pre-Lie algebras, depending on the ordering, a Grobner basis can 
vary from quadratic to seemingly infinite. On the other hand, for operads that do 
not have a quadratic Grobner basis, we encountered subtle performance issues in 
many cases. For operads having a relatively small finite Grobner basis, like the 



^The first author is a living example proving that it is possible; having been introduced to 
Haskell by the second author in the process of working on this package, he now has enough 
confidence to not only use the package, but to add new functions as well. 
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fake commutative operad AntiCom [ ], the computation easily yields the correct 
result, while for many other cases, like the pre-Lie operad for a "wrong" ordering, 
computations with arity 6 and further take enormously long. 

The actual implementation is distributed through the HackageDB repository for 
Haskell software projects at http://hackage.haskell.org/package/Operads — 
software distributed through this repository are available through the automated 
installation tool cabal-install. 

The current documentation files are kept online at http : //math . Stanford . edu/~mik/ operads/. 

1.2. Outline of the paper. The paper is organized as follows. In Section 2, we 
recall relevant background information related to operads and Grobner bases, on 
one hand, and to types and functions in Haskell, on the other hand. In Section 3, 
we discuss the way we chose to represent our data in Haskell. In Section 4, we 
present algorithms used in our implementation. Finally, in the appendix, we list 
Haskell constructions used throughout the paper. 

1.3. Acknowledgements. We wish to express our deep gratitude to Eric Hoffbeck 
and Henrik Strohmaycr for both significant assistance in the construction of the 
software code, and analysis of the techniques we are using. Some of the hairier 
points of Haskell evaluation has been rendered clear by the helpful assistance of the 
many members of the #haskell IRC channel on the Freenode IRC network. 

The first author was supported by an IRCSET research fellowship. The second 
author was supported by the Office of Naval Research, through grant N00014-08- 
1-0931. 

We are grateful to Jean-Louis Loday and Bruno Vallette who organized the 
"Operads 2009" meeting in CIRM Luminy, where the work on this project was 
started. The second author wishes to thank Dublin Institute for Advanced Studies 
which hosted him as a visitor during the last stage of working on this paper. 

2. Overview 

For exhaustive information on symmetric operads, we refer the reader to mono- 
graphs [ ] and [ ]. Here, we mainly concentrate on shuffle operads, and their rela- 
tionship with symmetric operads, and definitions in the symmetric case are chosen 
in the way that best suits this approach. 

2.1. Operads. We denote by Ord the category of nonempty finite ordered sets 
(with order-preserving bijections as morphisms), and by Fin — the category of 
nonempty finite sets (with bijections as morphisms). Also, we denote by Vect the 
category of vector spaces (with linear operators as morphisms; unlike the first two 
cases, we do not require a map to be invertible). 

Definition 1. (1) A (nonsymmetric) coHecfion is a contravariant functor from 
the category Ord to the category Vect. 
(2) A symmetric collection (or an E^-module) is a contravariant functor from 
the category Fin to the category Vect. 
For either type of collections, we can consider the category whose objects are col- 
lections of this type (and morphisms are morphisms of the corresponding functors) . 
The natural forgetful functor f : Ord —J- Fin, I i-^ leads to a forgetful functor ^ 
from the category of symmetric collections to the category of nonsymmetric ones, 
(/) := ^(/^). For simplicity, we let ^(fc) := -^{[k]). 
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We use the convention [fc] = {1, 2, . . . , fc} in this paper. 

Definition 2. • Let ^ and =S be two nonsymmetric collections. Define their 

shuffle composition ^ o^^ ^ by the formula 

k \f : I^[k] 

where the sum is taken over all shuffling surjections /, that is surjections 
for which min/~^(i) < min/~^(j) whenever i < j. 
• Let ^ and =S be two symmetric collections. Define their (symmetric) 
composition ^ o ^ by the formula 

fe \/: J^[fe] 

where the sum is taken over all surjections /. 

Each of these compositions gives a structure of a monoidal category on the 
category of the corresponding collections. The same definitions can be given if 
we replace Vect by another symmetric monoidal category. For our purposes, an 
important replacement for Vect will be the category of finite sets (with arbitrary 
mappings as morphisms). 

Definition 3. (1) A shuffle operad is a monoid in the category of nonsymmet- 
ric collections with the monoidal structure given by the shuffle composition. 

(2) A symmetric operad is a monoid in the category of symmetric collections 
with the monoidal structure given by the (symmetric) composition. 

Definition 4. A shuffle permutation of the type {ki, . . . ,kn) is a permutation in 
the symmetric group Ski+...+kr, which preserves the order of the first k\ elements, 
the second ^2 elements,. . . , the last fc„ elements, and satisfies 

cr(l) < a{ki + 1) < cr(fci + fca + 1) < . . . < cr(fci + . . . + kn-1 + 1). 

Proposition 1. The number of shuffle permutations of the type {ki, . . . ,kn) is 
equal to 

k\k2-----kn /ki + k2 + . . . + k, 

(fci + fc2 + . . . + fc„)(fc2 + . . . + kn) ■ . . . ■ kn\ fci, ^2, . . . , fc„ 

When implementing shuffle permutations, one can use tlie following simple idea: 
In a shuffle permutation, the number whose image is fci + . . . + /c„ should clearly be 
the maximal one in its block. Moreover, if this block is of size 1, it should be the 
last one to comply with the ordering condition on the first elements of blocks. This 
implies an obvious recursive algorithm to generate a list of shuffle permutations 
with given sizes of blocks: put the maximal image in the end of each allowed block, 
and for each such choice list all shuffle permutations where the corresponding block 
contains one element less than prescribed. 

Definitions. (1) Let ^ be a shuffle operad, P € ^(n), ai G ^{k\)-, 

Q!„ S i^(fc„). Assume that a G Ski+...+kn ''^^ ^ shuffle permutation of the 
type (fci, . . . , kn)- Denote by B^, s = 1, . . . , n, the s"^ block of [A;i + . . ■ + kn] 
(on which a is monotonous). Then we define 

/3(ai, . . . , an)a = o{l3 O ^(ai) ... a(a„)) G &{ki + ... + kn), 
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where a{as) is the miage of as under the isomorphism between ff{ks) and 
6'{(j{Bs)), and o: ff & ^ G \s the monoid product map. 
(2) Let ^ be a symmetric operad, /3 G G(ri), ol\ G ^(fci), . . . , a„ G G{kn). Let 
(T G S'fcj+...-(-fc„ be an arbitrary permutation. Denote by Bs, s — 1, . . . ,n, 
the s**^ block of [fci + . . . + fc„] (of size fc^). Then we define 

/3(ai, . . . , an)a = o(/3 cr(ai) ® . . . ® cr(a„)) G /^(fci + . . . + fc„), 

where cr(Qs) is the image of under the isomorphism between ff{ks) and 
^{(j{Bs)), and o: ^ ^ is the monoid product map. 

It turns out that the forgetful functor is a monoidal functor between the category 
of symmetric operads and the category of shuffle operads. Consequently, it turns 
out that to study various questions of linear algebra for symmetric operads, it is 
sufficient to forget the full symmetric structure because the shuffle structure already 
captures everything. See [-'i] for more details. 

2.2. Trees. Assume that we are given a collection of disjoint finite sets M(n), n > 1. 
A (rooted) tree is a non-empty directed graph T of topological genus for which 
each vertex has at least one incoming edge and exactly one outgoing edge. We allow 
for some edges of a tree to be bounded by a vertex at one end only. Such edges are 
called external. Each tree has one outgoing external edge, the output or the root, 
and several ingoing external edges, called leaves. All vertices of the tree should be 
decorated by elements of sets from the collection M; for a vertex with n inputs, the 
element used for the decoration should belong to M{n). Such a tree will be referred 
to as a nonsymmetric tree monomial. Usually, we consider such trees with some 
additional structure: for a tree with n leaves, we require the leaves to be labelled 
by [n]. For each vertex w of a tree, the edges going in and out of v will be referred 
to as inputs and outputs at v. A tree with a single vertex is called a corolla. There 
is also a tree with a single input and no vertices called the degenerate tree. Trees 
are originally considered as abstract graphs but to work with them we would need 
some particular representatives that we now are going to describe. 

For a tree with labelled leaves, its canonical planar representative is defined as 
follows. In general, an embedding of a (rooted) tree in the plane is determined 
by an ordering of inputs for each vertex (the leftmost one being the smallest, the 
rightmost — the largest). To compare two inputs of a vertex v, we find the minimal 
leaves that one can reach from v via the corresponding input. The input for which 
the minimal leaf is smaller is considered to be less than the other one. Planar rep- 
resentatives of decorated trees will be referred to as tree monomials. The collection 
of all tree monomials whose vertices are labelled by the collection M is denoted 
by ^M- 

Compositions of trees are defined as follows. Given a tree (3 with n leaves, 
trees ai, . . . , a„ with ki, . . . , fc„ leaves respectively, we define the composition 
f3{ai,a2, . . . , Qfn) as the tree obtained by grafting the tree ai to the first leaf of /3, 
the tree a2 with leaf labels shifted by ki to the second leaf of /3, . . . , the tree 
with leaf labels shifted by fci -I- . . . -I- fc„_i to the last leaf of /3. If, in addition, a 
is a shuffle permutation of [fci + . . . + fc„] of the type (fci, . . . , fc„), we can define 
the shuffle composition I3{ai,a2, ■ . ■ ,cxn)a, to compute it, we first compute the 
nonsymmetric composition of our trees and then apply a to the leaf labels of the 
resulting tree. 
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Remark 1. Let us emphasize two practicalities. First of all, the data type for 
trees chosen for an implementation should be easily adjustable for performing com- 
positions. Second, it is important here that we apply the permutation, not its 
inverse; usually, action of permutations on functions and mappings uses inverses, 
however, since operads are contravariant functors, we do not need that. One should 
be careful, and remember it when implementing the action of permutations. 

Proposition 2 ([ ]). (1) The collection of trees is closed under shuffle 

compositions. 

(2) Every tree in can he obtained from corollas by iterated shuffle compo- 
sitions. 

The collection is the free shuffle operad generated by the nonsymmetric 
collection M in the category of finite sets; its linear span is the free shuffle operad 
generated by the linear span of M in the category of vector spaces. 

Here and below by a divisor of a nonsymmetric tree monomial T we mean a non- 
symmetric tree monomial T' whose underlying tree is embedded into the underlying 
tree of T in such a way that the labellings of vertices are the same. 

For a tree monomial a with the underlying nonsymmetric monomial T and a 
divisor T' of T, let us define a tree monomial a' that corresponds to T' . Its vertices 
are already decorated, so we just need to take care of the leaf labelling. For each 
leaf I of T', let us consider the smallest leaf of T that can be reached from I. We 
then number the leaves according to these "smallest descendants" : the leaf with 
the smallest possible descendant gets the label 1, the second smallest — the label 2 
etc. 

Definition 6. For two tree monomials a,f3€ we say that a is divisible by /3, if 
there exists a nonsymmetric divisor of a for which the corresponding tree monomial 
a' is equal to f3. 

Remark 2. Checking divisibility is important for the Grobner bases algorithm. 
Thus, one has to put effort in finding an efficient implementation. Our approach is 
recursive; it is very much motivated by the choice of the platform. It would be very 
interesting to find a reasonably fast non-recursive algorithm for that, in the spirit 
of algorithms of Knuth-Morris-Pratt [ ] and Boyer-Moore [ ] for string divisibility. 

Proposition 3 ([■>]). A tree monomial a is divisible by /? if and only if a can be 
obtained from /3 by iterated .shuffle compositions with corollas. 

Assume that a is divisible by /?. Take some sequence of shuffle compositions 
with corollas that produces a from /3. This sequence can be applied to any tree 
monomial with the same number of arguments as /3; abusing the notation a little 
bit, we denote that operation on tree monomials by rua^p. This operation is actually 
well defined (that is, depends only on a and the specific subtree corresponding to 
the divisor /?, but not on any particular sequence of compositions that creates a 
from /?). 

Remark 3. Being able to compute the operations m^^^ in the most efficient way is 
crucial for the Grobner bases algorithm. This means that much thought should be 
put in the data representation philosophy; keeping the divisibility information in a 
logical way helps to be efficient. We chose the approach where a divisor is replaced 
by a "black hole" (or, in other words, by a new corolla); this way the operation 
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corresponds to the simple insertion of a tree in the hole. We explain it in 
more details in Section 3.3.3. 

Definition 7. A tree monomial 7 is called a common multiple of two tree mono- 
mials a and /3, if it is divisible by both a and /3. Tree monomials a and /3 are said 
to have a small common multiple, if they have a common multiple for which the 
number of vertices of the underlying tree is less than the total number of vertices 
for a and /3, and the embeddings of a and /3 in this common multiple cover all its 
vertices. 

Remark 4. Computation of small common multiples is one of the most frequently 
used operations in the Grobner basis algorithm. Our approach (described in detail 
below) shares certain similarities with the algorithm that lists all shuffle permuta- 
tions of the given type, even though is a little bit more sophisticated. 

2.3. Grobner bases. In this section, we assume that we are working with shuffle 
operads over Vect, in particular, we assume that the set of relations ^ consists of 
linear combinations of tree monomials. For the case of symmetric operads, pre- 
processing of the input data is required: first, the symmetric group action should 
be used to express operadic monomials in terms of tree monomials, second, the 
relations should generate the corresponding ideal as a shuffle ideal. For that, it is 
necessary that they form a symmetric subcollection, that is, are closed under the 
symmetric groups action. For example, if we add to the set of relations the orbit 
of each relation, this condition is automatically satisfied. 

In this section, we work with the free operad -^y, where the nonsymmetric 
collection Y is endowed with a basis, a collection of sets M. 

An ordering of tree monomials of is said to be admissible, if it is compat- 
ible with the operadic structure, that is, replacing the operations in any shuffle 
composition with larger operations of the same arities increases the result of the 
composition. In Section 4.3, we shall describe some admissible orderings. All results 
below are valid for every admissible ordering of tree monomials. 

Definition 8. For an element A of the free operad the tree monomial a is said 
to be its leading term, if it is the maximal monomial that occurs in the expansion 
of A with a nonzero coefflcient (notation: lt(A) = a). This nonzero coefficient (the 
leading coefficient of A) is denoted by c\. 

Remark 5. Whereas in the previous section we only worked with trees, from now 
on we use linear combinations of trees. Thus, it is important to implement working 
with tree polynomials, that is, linear combinations of tree monomials. The main 
requirement is that obtaining the leading term and the leading coefficient, being 
the most frequently used operations on polynomials, should be easy. 

Definition 9. Assume that / and g are two elements of for which the leading 
term of / is divisible by the leading term of g. The element 

c f 

rg{f) := / - — ™it(/),it(s)(.9), 
is called the reduction of f modulo g. 

Definition 10. Assume that / and g are two elements of ^y whose leading terms 
have a small common multiple 7. We have 

w^,it(/)(lt(/)) = 7 = "l^,lt(g)(lt(5))- 
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The element 

c f 

Sjif,g) ■■= m^,it{f){f) "i^,it(g)(5), 

is called the S'-polyiiomial of / and g (corresponding to the common multiple 7; 
note that there can be several different small common multiples) . 

S'-polynomials, as defined here, include the reductions as a particular case. It 
turns out to be convenient, but we shall need reductions on their own to deal with 
Grobner bases. 

Definition 11. Let ^ be an ideal of the free operad. ^ is called a Grobner basis 
of ^ , if for every f E ^ the leading term of / is divisible by the leading term of 
some element of 

The main fact about Grobner bases that makes them so useful is that the tree 
monomials that are not divisible by leading terms of a Grobner basis form a basis 
for the quotient of the free operad modulo ^ . Thus, knowing a Grobner basis for 
defining relations of an operad allows to obtain important information about this 
operad. 

Recall the Buchberger's algorithm for operads [.H]. Its input is a set ^ of relations 
between elements of the free shuffle operad . It repeatedly applies the following 
step: 

Step of the Buchberger's algorithm: Compute all pairwise S'- 
polynomials of elements of Reduce all these elements modulo ^ 
until they cannot be reduced further. Extend by joining these 
reductions to it. If there are no new elements joined, terminate. (If 
there are new elements, the step is repeated for the newly obtained 
set M.) 

2.4. Haskell. Haskell [■>] is a purely functional programming language with a pow- 
erful type system. Programming in Haskell has a declarative feel to it, in the sense 
that functions are defined by declaring equations for function evaluation — the 
equations are then used by the compiler with the first matching equation in the 
source code used for every application in the source code. 

We have built the implementation we are discussing in Haskell, and will use 
occasional source code excerpts for illustration through the paper. See the appendix 
for the list of all the Haskell-specific functions in use in our code examples. 

2.4.1. Types. Haskell depends on a strong adherence to its type system. Hence, 
any entity in the language possesses a type. There are types that are complete in 
themselves — such as Bool, Int, and types that are assembled from component 
types — such as the type [a] for lists containing elements of the type a. Functions, 
too, are first class citizens of the language, with a function taking input of type a 
and returning output of type b having type a — > b. 

Real power in the Haskell treatment of data types appears with the freedom 
to declare your own type. The most complete way to do this is with the data 
declaration. This allows, easily, for both record and union types; where a record 
contains one value of each of the specified values, and a union contains on value 
out of the specified values. 

As an example, similar to the datatype for trees that we will discuss at length in 
Section 3.1, a rooted tree is either a leaf node, or a root node with a list of subtrees. 
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The arity of the root node will be precisely the length of the list of subtrees. And 
a node of arity could be considered a leaf. 

Thus, we may define a tree data type using the declaration 

data Tree = Leaf | Node [Tree] 

Here, Tree is the resulting data type, and Leaf and Node are constructors for 
elements of the data type. A typical tree might look like: 

Node [Node [Leaf, Leaf], Node [Leaf, Leaf, Leaf]] 

The corresponding tree shape is shown in Figure 1. 




Figure 1. A tree shape 

This data type has been defined completely using the union type: a tree is either 
a leaf, or a node carrying a list of subtrees. We can extend the type using the record 
type construction into something that can carry labels both on leaves and vertices, 
making it usable to represent the decorated trees we use for representing operads. 

Thus, we can introduce two type variables, to make the resulting tree type ver- 
satile, and define a tree type that takes labels of any type for the nodes, and labels 
of any type — independent of the node type — for the leaves by: 

data Tree a b = Leaf a | Node b [Tree] 

Here, an element of the type Tree is either a leaf, equipped with a value of type 
a, or a node, equipped with a value of type b as well as a list of subtrees. 
Hence, an example of type Tree Char Int would be: 

Node 2 [Node 1 [Leaf 'a', Leaf 'b']. 

Node 3 [Leaf 'c', Leaf 'd', Leaf 'e']] 

The corresponding decorated tree is shown in Figure 2. 




'a' 'b' 'c' 'd' 'e^ 



Figure 2. A decorated tree 
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2.4.2. Functions. The second important part of understanding the way Haskeh 
works is the functions. A function is defined by its type, and by what it makes to the 
input arguments it takes. Haskell views a function with several input parameters as 
a function taking one value and returning a function expecting one less parameter. 
Thus (+) is a function that when applied to the value 2 will return a function (2+) 
that in turn increases its parameter by 2. 

A function specification in Haskell has two components. First ofi^ is the (optional) 
type declaration. An example, taken from our source code: 

operadicBuchberger : : 

(Ord a, Show a, TrccOrdering t, Fractional n) => 

[ OpcradElcment ant] — > [ OperadElement ant] 

This type declaration alone tells us a number of things about the function, 
and the parameters it takes and returns. First comes the name of the function: 

operadicBuchberger. It is the top level function to run the Buchberger algorithm 
on a set of operadic relations. Next is the :: — signifying that a type declaration 
follows. 

Following the name and the :: , we give an (optional) list of assumptions on the 
type variables involved in constructing all types of the type declaration: we need a 
to be a type that can be sorted and printed, we need t to be a TreeOrdering, i.e. 
an implementation of the monomial ordering algorithms we use. Finally, we expect 
n to be a numeric type implementing a field. 

Following the expectations follows the symbol =>, signifying the start of the 
actual type declaration. And we read off that the function has type 
[OperadElement ant] — > [OperadElement ant], or in other words that 
operadicBuchberger takes a list of operad elements with a certain type of vertex 
labels (signifying the operations in the free operad), a certain type of coefficients 
and a certain monomial ordering. 

After the type declaration, a sequence of equational declaration follow, contain- 
ing the bulk of the function definition. As a function is called, these equations are 
processed in the order they arc stated until one is found such that the left hand 
side of the equation matches the parameters submitted to the call. Once a match 
is found, the code on the right hand side is executed and the result is returned as 
the value; of the function call. 

Again, an example may be in order. We can write a function for the Tree type 
we described above that allow us to recognize leaves: 

isLeaf : : Tree a b — > Bool 

isLeaf (Leaf leaflabel) = True 

isLeaf (Node nodelabel subtrees) = False 

3. Internal representations 

Data representations and algorithms go hand in hand. A good algorithm will 
suggest a data representation that makes the steps of that algorithm easier; a good 
data representation will make the algorithms handling the data obvious and efficient 
from the storage methods. We have tried to find representations for the data types 
required for the Grobner basis algorithms that will make the subtasks we have 
identified easy to implement efiiciently. 
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We discuss representation for decorated trees in Section 3.1. The elements ol a 
free operad in the category Vect are formal linear combinations of decorated trees, 
and the representation of these is discussed in Section 3.2. Next up is the special 
type trickery needed to represent the black hole trees first introduced in Remark 
3 on page 5. We introduce two coproduct types useable for tagging vertices of 
trees while preserving some or all of the vertex tags in Section 3.3.1. This way, 
we can designate a corolla a black hole, or an embedding point in a small common 
multiple. We discuss the small common multiple structures in Section 3.3.2 and 
the black hole tagging in Section 3.3.3. Finally, we discuss the representation we 
use for permutations in Section 3.4. 

3.1. Decorated trees. We recall that the free operad is built with trees decorated 
at the corollas with elements of the generating graded set and with leaves decorated 
with an ordered set. 

While we expect the trees representing the basis of a free operad to have integer 
leaf labels, some of the lower level tasks are easier if we can also represent trees 
with other types of leaf labels. Hence, we will define one underlying tree type, 
PreDecoratedTree, and derive another tree type, DecoratedTree representing the 
basis elements of free operads. 

Hence, we will build our software with the decorated tree as our fundamental 
building block. We represent trees using a data type that encodes corollas and 
leaves as different, allowing each to carry a label. This guides us to the data type 
declaration 

data (Ord a. Show a) => 

PreDecoratedTree a b = 
DTLeaf !b | 
DTVertex { 

vertexType : : ! a , 

subTrees :: ![ PreDecoratedTree a b]} 
deriving (Eq, Ord, Read, Show) 

This is essentially the same as the tree type we discussed at the end of 2.4.1. 
It is decorated with more expectations, and some Haskell idioms to automatically 
generate functionality. Hence, the deriving clause will make the tree type auto- 
matically allow equality checks, sorting and methods to serialize and deserialize 
the data into strings. The sorting induced by the deriving clause, however, is 
not in general a monomial ordering, and we introduce further types in the code to 
introduce admissible monomial ordering. 

Furthermore, the vertexType and subTrees clauses automatically generate func- 
tion that allow us to extract the node label and the list of subtrees from a corolla. 

Since we occasionally, but not very often, will feel a need to decorate the leaves 
with something different from integers, we define our tree type as a different type 
from the type we use with the users in the end. We define a type synonym 
DecoratedTree a that stands for PreDecoratedTree a Int, so that the user should 
only ever have to see DecoratedTree occuring. 

We also define a number of utility functions for operations on these trees: meth- 
ods to apply a function to each node label, and to apply a function to each leaf label, 
as well as functions to easily construct corollas and leaves, and to easily determine 
the arity of a corolla and the total number of leaves of a tree. 
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One pattern that reoccurs a lot here is the basic tree recursion shape. We give, 
here, as an example, the code to apply a function to each vertex label: 

vertexMap : : 

(Ord a. Show a, Ord b, Show b) => 

(a — > b) — > PreDecoratedTree a c — > PreDecoratedTree b c 
vertexMap f (DTLeaf i) = DTLeaf i 
vertexMap f (DTVertex t ts) = 

DTVertex (f t) (map (vertexMap f) ts) 

There is some boiler plate — the type variables a and b have to match the 
assumptions needed to build a tree. But then the code just states that applying 
/ to the node labels if you encounter a leaf just returns the leaf unchanged. If, 
however, you encounter a vertex, you apply the function to the label and construct 
a new vertex with the new label and with the results from applying the function 
recursively to all subtrees. 

This structure faithfully reproduces planar rooted trees with leaf and node labels. 
Using the ordering on the leaf labels, we can represent any symmetric node-labeled 
tree this way. Using only the tree monomials from the free shuffle operad, finally, 
means placing restrictions on the permutations the leaf labels are allowed to display. 
Specifically, at any vertex, the minimal leaves of all its subtrees need to occur in 
sorted order in its list; this is exactly the choice of a planar representative from 
Section 2.2. Hence, in Figure 3, the left tree is a valid tree monomial, whereas the 
right tree is not. The points where the assumption fails are denoted by filled circles. 




1 32 4 5 61 3 



Figure 3. A tree monomial, and a decorated tree which is not a 
tree monomial 



3.2. Operad elements. Recall that an element of the free operad in the category 
of vector spaces over a field is a formal linear combination of decorated trees. To 
represent operad elements, thus, we need to be able to represent formal linear 
combinations — sorted according to the appropriate monomial ordering. 

Representing this computationally in Haskell is a three-step process. First, we 
represent monomial orderings. Then, we represent trees equipped with a monomial 
ordering. Finally, we use the Data. Map Haskell standard library implementation to 
represent a partially defined function taking decorated trees to coefficient values. 

These last functions become equivalent with formal linear combinations once we 
define an arithmetic on them: 
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{f + 9){a) = f{a)+gia) 
{c-f){a)=c-f{a) 

This equivalence is given by, for a function /, forming the formal linear combi- 
nation ^ f[a)a. The reverse is given by taking a formal linear combination ^ Caa 
and forming the function f : a t-^ Ca- 

Monomial orderings are represented as empty types — constructors without val- 
ues other than having distinct constructors. These types, then, are made to imple- 
ment type classes — the Haskell way to do polymorphism. Implementing a type 
class means that the type class defines specific functions, and the type class imple- 
mentation defines the implementation of these functions, in a separate manner for 
each type that implements the type class. We pair trees with orderings using the 
record type facility — a tree with an ordering is a tree paired with an ordering. A 
number of easy conversion functions between ordered and non-ordered trees make 
interfacing with this layering easier. 

As for the partial function definition, the datatype Data. Map works for finite 
such definitions by way of a lookup table: an entity of type Data. Map is a search 
tree that can be queried for the value associated to a particular tree, and that works, 
internally, by maintaining a balanced binary search tree. In particular, this makes 
the use of Data.Map very dependent on an efficient implementation of the monomial 
ordering methods, and one early adjustement we decided on was to overlay a thin, 
encapsulating module around Data.Map that would cache the relevant information 
needed to perform the most common monomial orderings. 

This last point is worth elaborating on. We found in early implementations that 
storing decorated trees in a binary search tree, and having monomial orderings de- 
pending on a significant number of tree traversals in order to construct the ordering 
invariants, lead to an extraordinary amount of tree traversals. In our first work- 
ing implementation, we found that over 60% of the computation time was spent 
traversing trees for comparisons triggered by the use of Data.Map for storage. Ev- 
ery operation on such operad elements would incur many tree comparisons, each of 
which would incur several tree traversals. To deal with this, we wrote a wrapper 
around the storage type that would perform the tree traversals for the orderings 
described in Section 4.3 once at the creation of an operad element, and store this 
with the tree. Subsequent interactions with this particular element would use this 
cached value for all comparisons — until the point a new element was constructed, 
as a modification of the previous one, at which point the comparison values would 
be recomputed. Using the wrapper, the proportion spent on tree comparisons and 
the related building block functions dropped to less than 5%. 

3.3. Trees with holes and tagged nodes. Recall that for two tree monomials 
a and /3 such that a is divisible by /3, it is possible to define the function ma,i3 that 
reconstructs the surroundings of /3 in a; this function is applicable to any other 
operad element of the correct arity. 

An algorithm for finding divisors of trees, as the Grobner basis algorithms makes 
heavy use of, would need an efficient way to represent the data needed for such a 
reconstruction. We decided to do this by representing holes punched in trees by 
corollas with a specific marking. 
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Similar to this idea is the data representation we found to be efficient to represent 
a smah common multiple of two trees in such a manner that the divisor data for 
both trees is easily reconstructed: such a small common multiple will have one of 
the trees dividing it at the root, and the other somewhere in the tree. We found 
a natural way, in Haskell, using union data types, to represent a tree with a single 
vertex marked. 

3.3.1. An aside on data types and labels. The union data type construction in 
Haskell has a standard library implementation, with quite a bit of predefined func- 
tionality: Either a b. This defines for us constructors Left and Right carrying 
values of types a and b respectively. 

One special case of the Either type is when one of the two types is empty. This 
case has been given a name of its own: Maybe a and comes with new construc- 
tors — Just taking the place of Left and Nothing taking the place of Right. 

These type constructions turn out to be exactly what we need to signify marked 
nodes and removed nodes. 

3.3.2. Trees with marked nodes. We generate, in order to mark some of the nodes of 
our tree, a new tree from the old one with changed node labels. Instead of labelling 
our tree with some type a, we now label them with Either a a. This has the effect 
of increasing the amount of information carried by each node — in addition to the 
original node information it now also carries a binary choice for each node: is it a 
Left or a Right instance of the label type? 

Hence, we can in our code for generating small common multiples return a tree 
labeled in Either a a, and making sure it only contains one single node labeled 
Right — namely the point of attachment for the second tree. We know that one 
of the two trees has to be rooted at the root of the small common multiple — 
otherwise it would not cover all vertices. 

The algorithm we use to find small common multiples, elaborated on in Section 
4.2, has the following basic structure. In order to find small common multiples of 
ai and a2 we go through the steps: 

(1) To find small common multiples of ai and a2 sharing the common root, 
traverse both trees, checking compatibility at each step and whenever one 
tree yields a leaf, attach the remaining subtree of the other tree. Tag the 
root of the returned small common multiple as Right label. 

(2) Recurse through vertices v of a2, applying the previous step to find small 
common multiples of ai and the subtree 02 of 02 rooted at v. For each 
such common multiple 7, form a new tree by taking a2 and replacing a2 
with 7. 

As a result, the only point where a node is tagged with the Right is when a 
rooted common multiple is found, and the recursion ensures that the rest of the tree 
is rebuilt so that 012 is embedded with a shared root with the common multiple. 

And in order to find all small common multiples, we need to perform this algo- 
rithm once again with the trees interchanged, so that we may find small common 
multiples with ai embedded at the root. 

3.3.3. Trees with holes. As for the divisor reconstruction, we have some embedding 
of the tree monomial /3 into the tree a, and we want to retain the information of 
the entire tree excepting the part that corresponds to /3. 
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The way we do this is to collapse the embedded copy of /3 into a single corolla 
of the correct arity, and keeping the rest of the tree intact. This corolla, then, is 
marked — forgetting any original corolla type markings — to signify that it forms 
an embedding point. 

This marking, in turn, is achieved by changing the type of all labels from the 
type a to the type Maybe a. That way, the part of the tree that needs to stay 
intact is marked with Just label for what previously was marked with label, and 
the corolla holding the position of the hole is marked with Nothing, distinguishing 
it from the other nodes. 

For this reason, we introduce the type alias Embedding a, defined to be of the 
type DecoratedTree (Maybe a) . Hence, the division algorithm described in Section 
4.1 will take the two trees a and /3 as parameters, and return an embedding of the 
shape of a with a subtree isomorphic to (3 taken out. See Figure 4 for an example. 




1245789 12 789 



Figure 4. Taking away a subtree results in a tree with a hole 

The reconstruction algorithm, on the other hand, takes a shape representing 
some embedding of /? in a, and a new tree monomial 7 of the same arity as /?, and 
returns the corresponding tree ma.j3{'^). 

3.4. Permutations. Since the most common use for permutations in this project 
is to label leaves of trees, and to reorder subtrees for composition, we have decided 
to store our permutations as lists of images. This choice is reinforced by the lack 
of need for compositions and decompositions of permutations. 

This representation yields a simple method to reorder a list of objects in the 
order specified by a permutation — an operation we have reason to perform often 
in the code, for instance in order to decorate leaves of a labelled tree according 
to their integer decorations: we pair off the elements we want to reorder with the 
image list. Then we sort the pairs, giving priority to the comparison of the image 
indices. Stripping off the indices, finally, gives us the reordered list of elements. 

This is a code idiom we have used at several points in the code base. 

4. Algorithms 

With the data structures we use settled in Section 3, we now turn to the algo- 
rithms that implement the core components of the Buchberger algorithm. Thus, 
in Section 4.1, we meet the division algorithm, creating the black hole trees, and 
the reconstruction algorithm, re-inserting a tree in the black hole. In Section 4.2, 
we adapt the idea for finding block permutations to give us an efficient algorithm 
for finding small common multiples. Finally, in Section 4.3 we discuss the family 
of monomial orderings that the software package implements. 
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4.1. Divisibility and reconstructions. Finding all embeddings (as a divisor) of 
/? into a can be easily reduced to finding out whether or not /3 is embedded into a in 
such a way that they share the common root. If we know how to solve this problem, 
we should just solve it for all subtrees a' of a rooted at various vertices. To solve 
this problem, it suffices to recurse down the tree checking that the same holds for 
all subtrees, and then check that the total leaf orderings match. At this stage, to 
check that the orderings match, one can look at the planar orders of leaves and 
compare them; this appears to be the best way to do it for our recursive algorithm. 

Specifically, if we try to find an embedding of /3 into a sharing the common root, 
we first verify that the root vertices share the label and arity. If this is the case, 
we can pair up the subtrees /3i of /? and the subtrees of ai of a, and then find 
rooted embeddings of each /3i in each ai. If all these succeed, we expect to get as 
a result from each a tree 1110^,13^ for each pair with a hole punched out at the root 
corresponding to a subtree looking like /3i . 

At this point, we need to patch things up. The root nodes match, and the 
subtrees have already found embeddings. Checking the leaf orders, we then need 
to merge all the subtrees with holes into a tree with hole that gets returned up to 
earlier recursion levels. This is done by simply creating a new hole vertex, and then 
attaching all subtrees of the hole subtrees, as shown in Figure 5. 




1 3 4 5 1 3 4 5 



Figure 5. Merging subtrees with holes 

Once we find an embedding of /3, we store this embedding as a tree monomial 
obtained from a by collapsing the occurrence of /3 into a single vertex. To recon- 
struct a from that, we insert (3 in the "hole" in such a way that the leaves of (3 
match the outputs of the "hole" (order- wise) . 

Inserting (3 into the hole, specifically, means that we replace the leaves of (3 with 
the subtrees of the hole in the tree with the hole, in the order specified by the labels 
of the leaves of /?, and then replace the hole and all its subtrees in the full tree with 
a hole by this extended /3, as shown in Figure 6. 

4.2. Finding small common multiples. An algorithm that lists all small com- 
mon multiples of two given trees ai and a2 consists of several steps. If we forget all 
leaf labels of a tree monomial, we end up with a planar tree with labelled vertices. 
We call such tree a nonsymmetric tree monomial; such trees form a basis in the 
free nonsymmetric operad generated by the same nonsymmetric collection as our 
free shuffle operad. Describing all small common multiples is naturally split into 
two steps: forgetting about leaf labels and finding a nonsymmetric small common 
multiple, and then acquiring all possible leaf labellings of the resulting trees. 
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Figure 6. Inserting a tree in a hole 



The first step is more or less trivial: small common multiples of two nonsym- 
metric tree monomials are superpositions of the trees for which all labels of vertices 
agree with each other. Thus, to list all such small common multiples, we should 
go through all ways to identify the root vertex of one of the trees with a vertex of 
another tree, and check that there are no contradictions between the successors of 
these two vertices. This can be easily done recursively. 

The second step is a bit more tricky, but still requires a straightforward recursive 
algorithm. To recover all admissible leaf labellings giving a common multiple a, we 
have to solve the problem of finding all possible linear orders on a poset of a special 
type. The elements of that poset are leaves of the nonsymmetric tree monomial, 
and we say that a < 5 if there exist two vertices u and v of the nonsymmetric tree 
monomial such that 

• a is the smallest leaf reachable from u and b is the smallest leaf reachable 
from v; 

• u and V are leaves of the occurence of ai in a (where i is either 1 or 2), and 
u < V m the ordered leaf set of a^. 

A labelling of the leaves of a makes it a small common multiple if and only if it 
extends the above ordering to a linear ordering. We shall recover all such labellings 
recursively. Our poset essentially consists of two intertwined and intersecting linear 
orders, and the maximal element of the labelling set should label the maximal 
elements of one of the two orders (under the additional condition that it cannot 
occur as a non-maximal element in the other linear order). For each such option, 
we are left with a similar problem where the size of the labelling set is one less, so 
we can use recursion. 

4.3. Monomial orderings. Let us describe some admissible orderings. As one can 
see, each definition will be either immediate to implement because of the storage 
types we use or straightforward recursive. 

Let a be a tree monomial with n inputs in the free operad J^m- We associate 
to a a sequence (ai, 02, . . . , a„) of n words in the alphabet M , and a permutation 
5 G S'n as follows. For each leaf i of a, there exists a unique path from the root to i. 
The word ai is the word composed, from left to right, of the labels of the vertices 
of this path, starting from the root vertex. The permutation g lists the labels of 
leaves in the order determined by the planar structure (from left to right). 

Now, to compare two tree monomials we always compare their arities first. If the 
arities are equal, there are several different options of how to proceed. Sequences 
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of words can be compared lexicographically using either the degree-lexicographic 
ordering of words, or the reverse degree-lexicographic ordering (either the longer 
word is greater, or vice versa; for words of the same length the comparison is lex- 
icographic). Permutations can be compared in the lexicographic or reverse lexico- 
graphic order. Also, the result depends on what we compare first, the permutations 
or the sequences of words. This gives rise to eight candidates for an ordering; we 
name these candidates PathPerm, RPathPerm, PathRPerm, RPathRPerm, 
PermPath etc. (the names are self-explanatory). 

Proposition 4 ([ ]). All the above orderings are admissible. 

In fact, to compare words one may use any admissible ordering of the monomial 
basis of the free algebra, for example, the lexicographic ordering, or the reverse 
lexicographic one: the resulting ordering of tree monomials will be admissible as 
well. 

Appendix: Haskell constructions used 

Bool: The boolean truth values type. Has values True and False. 

Int: The bounded integer type. Has values, on a 32 bit machine, from the 

interval [-2147483648, 2147483647]. 
Char: The single character type, 
[a] : The type of lists of elements of type a. 
a — !■ b: The type of a function from a type a to a type b. 
data: The declaration of a new data type. 

Ord: The type class that defines the ordering functions <, >, <=, >=, and 
compare. 

Eq: The type class that defines the equality testing function (==). 
Show: The type class that defines the serialization function show. 
Fractional: The type class that defines a type to implement a field. 
(::): The syntax element indicating a type declaration. 

(=>): The syntax element delimiting type assumptions from the type decla- 
ration. 

(!): When occurring in a type declaration, forces strictness in the correspond- 
ing part. 

(I): When occurring in a type declaration, delimiting the union type compo- 
nents. Hence, a type declared as data T = A Int | B Char is either an 
Int with the constructor A, or a Char with the constructor B. 

TreeOrdering: A type class created by our code carrying information about 
the chosen monomial order. 

OperadElement: The type created by our code representing, internally, a 
linear combination of tree monomials with associated monomial orderings. 

(+): The addition function. 

deriving: Used in a data declaration. It will automatically generate imple- 
mentations of the type classes listed. 

map: A higher order function that applies another function to every element 
in a list. 
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